Content synchronization between electronic devices

ABSTRACT

A method is provided for transferring content between a first mobile device ( 10 ) and a second mobile device ( 20 ). The method includes: internally storing the content on the first mobile device ( 10 ) using a first data representation for the internally stored content on the first mobile device ( 10 ); establishing a common syntax and associated semantics for describing the content; creating a first external manifest ( 16 ) on the first mobile device ( 10 ) from the internally stored content on the first mobile ( 10 ), the first external manifest ( 16 ) employing the common syntax and associated semantics to describe the content; transferring the content from the first external manifest ( 16 ) to a second external manifest ( 26 ) created on the second mobile device ( 20 ), the second external manifest ( 26 ) also using the common syntax and associated semantic to describe the content; and, internally storing the content on the second mobile device ( 20 ) using a second data representation for the internally stored content on the second mobile device ( 20 ).

FIELD

The present inventive subject matter relates to the art of electronicdevices. Particular application is found in conjunction with certaintypes of mobile electronic devices, and the specification makesparticular reference thereto. However, it is to be appreciated thataspects of the present inventive subject matter are also amenable toother like devices and/or applications, e.g., non-mobile device.

BACKGROUND

Various types of mobile electronic devices are generally known in theart. Cellular or wireless or mobile telephones, smart phones, personaldigital assistants (PDAs), etc. are common examples of such mobiledevices. It is customary for a mobile device to be equipped with amemory or other data storage element in which information, data and/orvarious contents are maintained. More specifically, typical mobiledevices are often provisioned, for example, with a contact list, addressbook or the like in which names, telephone numbers, street addresses,e-mail addresses and/or other information regarding various individualsor other contacts are stored.

On occasion, a user may desire to synchronize, transfer, upload orotherwise send content from one mobile device to another. For example,when acquiring a new mobile telephone, a user may desire to transfer thecontact list from the old mobile telephone to the new one. In anotherexample, a user may desire to synchronize the contact list on theirmobile phone with the contact list on their PDA in order to keep therelevant information up to date. However, prior art solutionsimplemented to execute this task can be undesirable for one reason oranother.

In one prior art example, a user may have to manually enter theinformation or data into the mobile device receiving the content. Morespecifically, the user would simply enter the new or updated datamanually into the contact list of the mobile device, e.g., using thekeypad or other input device equipped on the mobile device. However,this can be an overly time consuming and/or painstaking process that isprone to errors due to mistaken user input, particularly if there aremany entries to be made. Moreover, due to size constrains, many mobiledevices are often equipped with limited input devices, e.g., as comparedto a standard or full keyboard. This can make manual data entry all themore undesirable.

In another conventional example, when a user purchases or otherwiseacquires a new mobile telephone, the telephone seller or provider mayprovide a service whereby the contact list from the old mobile phone istransferred to the new mobile phone while the user waits. However, thiscontact list transfer service is often not offered when a user switchesbetween different wireless service providers and may not be availablefor all types or models of mobile devices. Additionally, to avail one'sself of this service, the user is generally required to have the oldmobile phone with them when the new mobile phone is purchase oracquired, which may not always be the case, or they may be required toreturn to the point of purchase or other authorized service center at alater time with both mobile devices; this is especially true since thenew device may have to be charged for several hours prior to beingoperative in order to begin the transfer of data. As can be appreciated,such a return trip may be inconvenient for the user. Moreover, this typeof contact list transfer service is generally only available fortransfers between specific mobile telephones. Accordingly, a user wouldnot, e.g., be able to synchronize contact information between a PDA anda mobile phone using this service. Also, certain new mobile devices orphones may be completely incompatible for data transfer purposes witholder devices the user may possess.

Generally, a straightforward transfer of contact list/address book databetween mobile devices is hindered by the fact that different mobiledevice, e.g., from different manufactures, have different ways and/orformats for the internal representation and/or storage of the relevantdata and there is generally no well adhered to standard for data storageand/or the representation of contact list data on mobile devices.Rather, manufactures typically try to devise the most efficient way tostore the contact list data on the mobile devices, and data accessgenerally follows the same strict constrains.

Additionally, different mobile devices may have different kinds of datastored in each entry or record of the contact list, e.g., depending onthe mobile devices capabilities and/or the manufacture's desire. That isto say, one mobile device may support a rather rudimentary set of datain its contact list for each entry or record, e.g., a contact name and acontact number, while on the other hand another mobile device maysupport a more extensive set of data in its contact list for each entryor record, e.g., a contact name, multiple contact numbers, a speed dialdesignation, a group designation, a ring tone selection, an associatedimage designation, etc. Additionally, other mobile devices may furthersplit the contact name into separate fields, such as a first name and alast name. Accordingly, as can be appreciated, different mobile devicescommonly employ different internal data structures for their contactlists and/or different internal representations of the contact listdata, e.g., which is often driven by the different capabilities of themobile devices.

To address the aforementioned inconsistencies between different mobiledevices, external “data converter” programs or applications, e.g.,available on the Internet, have been developed. These data conversionprograms attempt to solve the inconsistency problem by providingconversion routines that are operable for a particular pair of mobiledevices (i.e., a specific source device and a specific destinationdevice) and apply data transformations specially designed for theidentified pair of mobile devices so that the specific destinationdevice is able to recognize and/or accept the contact list data from thespecific source device. The drawback here is that unless a user canlocate the particular source device and destination device pair, theroutine generally cannot be used. As a multitude of various new typesand/or models of mobile devices are introduced and/or created bydifferent manufactures on a fairly regular basis, relying on these typesof data converters is a limited option. Moreover, as manufactures mayconsider their own newly developed internal data structures and/or datarepresentations to be proprietary or secret, they may be unwilling orhesitant to release the specifications of the data structures and/ordata representations to those that would develop appropriate dataconverters for the respective mobile device employing these datastructures and/or data representations for their contact list data.Accordingly, the development and/or availability of a suitable contactlist data converter may be prohibited, delayed or otherwise hindered.Additionally, using Internet based data converters represents a securityrisk to the extent that a user's contact list data may be exposed tounauthorized or otherwise unwanted tapping by the provider of theconverter or while it is being transmitted over the Internet.

Accordingly, a new and improved method for synchronizing content betweenmobile devices is disclosed that overcomes the above-referenced problemsand others.

SUMMARY

In accordance with one embodiment, a method is provided for transferringcontent between a first mobile device and a second mobile device. Themethod includes: internally storing the content on the first mobiledevice using a first data representation for the internally storedcontent on the first mobile device; establishing a common syntax andassociated semantics for describing the content; creating a firstexternal manifest on the first mobile device from the internally storedcontent on the first mobile, the first external manifest employing thecommon syntax and associated semantics to describe the content;transferring the content from the first external manifest to a secondmobile device using an external manifest created on the second mobiledevice, the second external manifest also using the common syntax andassociated semantic to describe the content; and, internally storing thecontent on the second mobile device using a second data representationfor the internally stored content on the second mobile device.

In accordance with another embodiment, a method is provided fortransferring content from a first mobile device to a second mobiledevice. Suitably, the content includes a plurality of different types ofdata elements, each particular data element having a particular value,wherein the content is stored internally on the first mobile deviceusing a first device-specific internal data representation and thecontent is stored internally on the second mobile device using a seconddevice-specific internal data representation. The method includes:establishing a plurality of commonly recognized labels for identifyingthe different types of data elements; communicating from the firstmobile device to the second mobile device a first list containing one ormore of the commonly recognized labels, wherein the labels contained inthe first list indicate which types of data elements are available fortransfer from the first mobile device to the second mobile device;communicating from the second mobile device to the first mobile device asecond list containing one or more labels selected from the first list,the selected labels contained in the second list indicating which typesof data elements are to be transferred from the first mobile device tothe second mobile device; and, transferring from the first mobile deviceto the second mobile device the values of those data elements identifiedby the selected labels contained in the second list.

Numerous advantages and benefits of the inventive subject matterdisclosed herein will become apparent to those of ordinary skill in theart upon reading and understanding the present specification.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive subject matter may take form in various components andarrangements of components, and in various steps and arrangements ofsteps. The drawings are only for purposes of illustrating preferredembodiments and are not to be construed as limiting. Further, it is tobe appreciated that the drawings are not to scale.

FIG. 1 is a block diagram illustrating an exemplary configuration ofmobile devices suitable for practicing aspects of the present inventivesubject matter.

FIG. 2 is a pillar-post type diagram illustrating a data transferprotocol in accordance with aspects of the present inventive subjectmatter.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

For clarity and simplicity, the present specification shall refer tostructural and/or functional elements, relevant communication standards,protocols and/or services, and other components that are commonly knownin the art without further detailed explanation as to theirconfiguration or operation except to the extent they have been modifiedor altered in accordance with and/or to accommodate the preferredembodiment(s) presented herein.

Generally, the present specification describes a mechanism that allowsfor a mobile device to associate semantics and/or meaning with storeddata and defines an interface protocol that is understood and/orrecognizable by other mobile devices, thereby supporting the transfer ofcontent (e.g., contact list data) between different types and/or modelsof mobile devices. Suitably, a synchronization agent (“sync agent”)interprets the semantics and facilitates the data transfer in accordancewith a common protocol described herein.

As pointed out in the background, different types and/or models ofmobile devices are commonly provisioned with contact lists or the likeand the various different types and/or models of mobile devices oftenemploy different data structures and/or different internalrepresentations of the data contained therein. While differing types ofdata elements are typically supported by various different mobiledevices, there is by and large a common set of data elements are usedacross these mobile devices and the basic data elements, e.g., contactname and contact number, generally remain inherent in each contact list.Tying these like data elements together via a common syntax forrepresenting the element types and an associated semantics support thefunctionality described in the present specification.

In accordance with the present specification, the syntax and semanticsof data elements stored in mobile devices is formalized so as tofacilitate migration of data between mobile devices in an automated waywith minimal user intervention. Suitably, this is achieved withoutchanging the mobile device's internal representation of the dataelements. Rather, an external manifestation is provided to aidmigration.

With reference to FIG. 1, two mobile devices suitable for practicingaspects of the present inventive subject matter are illustrated. Forpurposes of the description herein, the first mobile device 10 isdesignated as the source or sending device and the second mobile device20 is designated as the destination or receiving device. Suitably, themobile devices are mobile telephones, smart phones, PDAs, or the like.As illustrated, each mobile device is equipped or otherwise provisionedin the usual manner with a contact list (12 and 22 respectively) or someother like data storage capability. As can be appreciated, for differenttypes and/or models of mobile devices, the internal representation ofthe data maintained in each contact list is suitably specific to theparticular mobile device.

Associated with each mobile device is a sync agent (14 and 24respectively). Suitably, the sync agent 14 supports an external datamanifest 16, a device-native interface 17 to the internal datamaintained in the contact list 12 and an external interface 18.Likewise, the sync agent 24 supports an external data manifest 26, adevice-native interface 27 to the internal data maintained in thecontact list 22 and an external interface 28.

On one hand, each sync agent works with its corresponding external datamanifest in a universal manner to facilitate data transfer between thetwo mobile devices, while hiding the details of the internal datarepresentation or structure employed in their respective contact lists.On the other hand, each sync agent also works with its correspondingdevice-native interface to access the internal data maintained in therespective contact lists. That is to say, the sync agent of each mobiledevice uses their external data manifest when the mobile devicesinterface with one another for data migration. Suitably, a data mappingpart or function internal to the sync agent is used to correlate theexternal and the native data formats.

Preferably, the sync agents, the device-native interfaces, external datamanifests as well as external interfaces are all to be put on thedevices by the device manufactures or their designated proxies or devicevendors. That is to say, the agents and/or related components becomepart of each device, rather than an overlaid application. This isadvantageous because the device manufacturers know the device-specificinternal data representation that they are employing.

In a suitable embodiment, the external interface from the sync agentfollows a high-speed serial bus connection as most mobile devices arecompatible with USB (Universal Serial Bus) connectivity. Alternately,other physical mediums for the interface between the mobile devices arecontemplated and various examples are presented later herein.

Two aspect of the present inventive subject matter will now bedescribed. First, a common syntax for data representation in theexternal data manifest is set forth along with its associated semantics.This is followed by a description of an exemplary implementationoutlining a protocol for the transfer of data.

Syntax/Semantics of External Data Manifest

In one exemplary embodiment, the syntax for data representation in theexternal data manifest follows a Lightweight Directory Access Protocol(LDAP) or LDAP-like representation in which each record in the manifestincludes a distinguished name (Dn). Suitably, each record in themanifest is a collection of data elements, with each data elementfollowing a nomenclature commonly understood and/or recognized also byother mobile devices. For example, the following is a suitable textrepresentation for the data in the manifest 16 of the sending device 10:

Dn: John Doe, Fn: John, Ln: Doe, Nn: Scooter, M1: 6143251111,

M2: 6143542222, HT1: 6148553333, WT1: 6143674444, E1:

johndoe@lucent.com, E2: Johndoe@yahoo.com, S:

sip:john@lucent.com, I: John.jpg, D:1, G:1, R:5, . . . .

As can be seen in the present example, each data element is identifiedby a unique label or keyword (“Dn”, “Fn”, “Ln”, etc.), followed by acolon (“:”), followed by the value of the field (e.g., “John Doe”).Individual data elements are separated by commas (“,”).

Table 1 below illustrates an example of how the foregoing record appearsin the external data manifest 16 of the sending device 10. Please note,however, that the “Meaning” column is included here for explanationpurposes only; in practice, most devices would not store a verbosedescription of the fields in the record.

TABLE 1 Example External Manifest No. Keyword Value Meaning 1 Dn JohnDoe This is the distinguished name for the record 2 Fn John This is thefirst name 3 Ln Doe This is the last name 4 Nn Scooter This is thenickname 5 M1 6143251111 This is the first mobile number of the record 6M2 6143542222 This is the second mobile number of the record 7 HT16148553333 This is the first home telephone number for John 8 WT16143674444 This is the work telephone number for John 9 E1johndoe@lucent.com John's primary email contact 10 E2 Johndoe@yahoo.comJohn's secondary email 11 S Sip:john@lucent.com John's SIP address 12 IJohn.jpg John's image, e.g., the type is optionally one of{.gif|.jpg|.jpeg| other} 13 D 1 Speed Dial entry 1 14 G 1 Group entry 115 R 5 Ringer-type 5 16 . . . . . . . . .

Similarly, for the receiving device 20, an exemplary external manifestmay be more rudimentary, e.g., suitably taking the following form:

TABLE 2 Example External Manifest No. Keyword 1 Dn 2 M1Significantly, the meaning associated with Dn and M1 in Tables 1 and 2are identical. However, Table 2 has been presented here without themeaning of the fields separately described in a column of its own sincethis has already been done in Table 1.

Please note that for data transfer purposes between the two mobiledevices, the internal data structures of the mobile devices' respectivecontact lists are irrelevant insomuch as the sync agents' data mappingfunctions and device-native interfaces correlate the data between theexternal manifests and the contact lists. Rather, the externalmanifestation of the data is the only point of interest in this regard.

While in this example, Table 1 shows a superset of what is supported onthe receiving device 20, that is not strictly the case. The object ofthe table is to impose a set of common keywords and their semanticsacross a range of various different mobile devices. In practice, not allthe parameters/data elements would be represented in the table ofvarious mobile devices. Rather, the illustrated table serves as a basetable for commonly used data elements. That is to say, extensionsspecific to particular mobile devices are contemplated, and not allmobile devices are expected to support all types of data elements and/orthe contemplated extensions.

The examples and the tables above show a canonical form for externalrepresentation of the data elements. Nevertheless, variations arepossible, e.g., by extending the namespace for addressing data elements,or changing the keywords themselves (e.g., one variation of “E1” couldbe “EM1” or even “email1”); or by using different characters as dataseparators or as keyword/value separators. It is to be appreciated thatthese variations do not deviate from the spirit of the present inventivesubject matter. However, the keywords and syntax should remain uniformlyunderstood and/or recognized across various different mobile devices.

Data Transfer

Given that each mobile device can provide an external manifestation ofthe data elements via a common syntax, the data migration can now bedescribed in two further sub-sections—the first, addressing a suitableprotocol for the transfer of the data, and the second, addressing thephysical medium over which the data is transferred.

Protocol

For this example used to illustrate the data transfer protocol, it shallbe assumed that a user wants to transfer data from the contact list 12of the first mobile device 10 to the contact list 22 of the secondmobile device 20. Suitably, the transfer is a non-destructive read-out,in that the source is not destroyed after the read-out. Also, if thereis prior data existing in contact list 22, that data remains intact; inother words, the contact list 12 is appended to contact list 22.

With reference now also to FIG. 2, there is illustrated an exemplaryexchange of signals and/or messages over a communication link 30 (seeFIG. 1) between the mobile devices 10 and 20 which is suitable forimplementing a data transfer protocol in accordance with aspects of thepresent inventive subject matter. As illustrated in FIG. 1, thecommunication link 30 is established between the external interfaces 18and 28 of the respective sync agents 14 and 24.

The exemplary protocol illustrated in FIG. 2 for effecting the datatransfer is as follows:

Step 1. The user invokes the sync agents on each mobile device. That isto say, on the mobile device 20 the user identifies to the agent 24(e.g., via an appropriate input) that it should act or otherwise operatein a “receive” mode, and on the mobile device 10 the user identifies tothe agent 14 (e.g., via an appropriate input) that it should act orotherwise operate in a “send” mode. Optionally, for security purposes,both agents would request or seek a password or passcode or other likeuser input before accepting a user's command to send/receive data.

Step 2. The sender sync agent 14 transmits, e.g., in clear text (ASCII),its role identification to the receiver sync agent 24. Optionally, themessages and/or signals exchanged are clear text messages, e.g., ASCII(American Standard Code for Information Interchange) or the like.Suitably, the sender role identification message is optionally “TX”which is short for “transmit”. If the “TX” message goes unanswered, thenthe sender agent 14 waits for a period of time before sending another“TX”. If case several “TX” messages go unanswered, the sender agent 14then gives up and quits or shuts down.

Step 3. Suitably, when the “TX” message is received from the sendingagent 14, the receiver sync agent 24 acknowledges the role of thesender, by sending an “ACK” message or other similar signal back. Onreceipt of this “ACK”, the sender stops sending its “TX” message. Notethat in case of mis-configuration, e.g., where both devices have beenincorrectly identified as sender devices, both devices start sending“TX” in step 2; suitably, this deadlock is broken by any of the devicessending a negative acknowledgment, or a “NAK”, after which both devicesstop sending the “TX”.

Step 4. Suitably, after acknowledging the role of the sender sync agent14, the receiver sync agent 24 further clarifies its role by sending a“RCV” message (i.e., short for “receive”).

Step 5. The sender sync agent 14 acknowledges receipt of the “RCV”message by sending an “ACK” back to the receiver sync agent 24.

Step 6. At this time, the receiver sync agent 24 makes the sender syncagent 14 aware of its capacity for receiving and/or accepting data. Thatis to say, suitably, the receiver sync agent 24 sends a count to thesender sync agent 14 (e.g., in digits, such as “250” or some othervalue), to indicate its capacity for accepting data.

Step 7. Receipt of the data capacity message is acknowledged by thesender sync agent 14 sending an “ACK” message back to the receiver syncagent 24. (Note: If the sender sync agent 14 has more data records tosend than the count received, the sender sync agent also alerts the userthat the receiving device is not capable of storing all of the dataavailable on 10. It should be appreciated that there can be multiplesuch “error” cases; however, all such cases are not described for thesake of brevity, nevertheless, in practice these “error” cases aresuitably addressed in like manner.)

Step 8. At this point, the sender sync agent 14 suitably initiatessending the manifest by first sending a “MANIFEST” header.

Step 9. Receipt of the “MANIFEST” header is acknowledged by the receiversync agent 24 sending an “ACK” message back to the sender sync agent 14.

Step 10. Now, the sender sync agent 14 sends the manifest, suitably, ina single transmission. Via a listing of the commonly recognizedkeywords, this message identifies which types of data elements areavailable for transmission from the sending device 10. Using the exampleabove, the sender sync agent 14 sends, for example, a message whichlooks like:

Dn, Fn, Ln, Nn, M1, M2, . . . .

As can be appreciate, this message lists the types of data elementsavailable from the sending mobile device 10, where the data elementtypes are indentified using the commonly recognized and/or understoodkeywords designated therefor in the external data manifest 16.

Step 11. The receiver sync agent 24 responses by sending back a messagelisting the types of data elements it wishes to receive. Again, the dataelement types are indentified using the commonly recognized and/orunderstood keywords designated therefor in the external manifest 26.Suitably, the order in which the keywords appear in the message,indicates the order in which receiver sync agent 24 would like orexpects to receive the data. Again, using the example above, theresponse sent by the receiver sync agent 24, is, for example, a messagethat looks like:

Dn, M1.

As can be appreciated, this message lists the types of data elementsdesired by and/or supported on the receiving mobile device 20, where thedata element types are indentified using the commonly recognized and/orunderstood keywords designated therefor in the external data manifest26.

Step 12. Receipt of the response is acknowledged by the sender syncagent 14 sending an “ACK” message back to the receiver sync agent 24.

Step 13. Suitably, the receiver sync agent 24 declares itself ready toreceive data by sending a “DATA” message or other like signal.

Step 14. In response to receipt of the “DATA” message, the sender syncagent 14 starts sending the data, e.g., in a continuous stream.Optionally, a header such as “RESP:” (short for “response”) or otherlike header is the first element in the data stream or otherwiseprecedes the actual data. Accordingly, the data stream messageoptionally looks as follows:

RESP: John Doe, 6143678888, Jane Doe, 6307131111, . . . , John Doe n,6306232222. (Note that the receiving device can only accept Dn and M1,hence the sender device does not send the other fields of each of therecords.)

Step 15. Once the receiver sync agent 24 has finished receiving the datastream, it sends back a count of the records received. For example,assuming 100 records were received, the receiver sync agent 24 wouldsend “100”.

Step 16. Assuming the sender sync agent 14 had sent 100 records, thesender sync agent 14 confirms the record count by sending an “ACK”.

Step 17. Having now completed the data transfer, the receiver sync agent24 disengages, e.g., by transmitting a “BYE” message of other likesignal.

Step 18. Similarly, the sender sync agent 14 responds with another “BYE”to complete the disengagement of the two mobile devices 10 and 20.

Step 19. Now, the receiving sync agent 24 is free to input the receiveddata into its internal data tables (i.e., the contact list 22) using theinterface 27 and the mapping function that correlates data from theexternal data manifest 26 to the contact list 22. Suitably, therespective sync agents are implemented by the manufacturers of thedevices or their appropriate proxies, so that translation of theexternal manifestation of the data into the appropriate data structureor representation used internally can readily be achieved by therespective sync agents without knowledge of the internal datarepresentations having to be shared publicly. Moreover, certaininconsistencies between different types of internal data representationcan be selectively addressed as each manufacturer sees fit. For example,if Dn uses 20 characters on the sender side, but only 15 characters onthe receiver side, the receiving agent may elect to simply truncate orcut off the trailing extra characters before putting this data into thereceiving side Dn. Another possibility is that the manifest itself canshare the width of each field.

While in the foregoing example, the sending device 10 supportsadditional field in its contact list 12 as compared to the receivingdevice 20, this is not strictly the case in practice. On the contrary,typically when users move from one device to another, the latter deviceis often more modern and/or advanced. Along those lines then, in theforegoing example, the roles of the sending and receiving devices and/orthe capabilities thereof may suitable be reversed.

Physical Medium

In suitably, embodiments, there are several ways to interconnect thesending and receiving devices 10 and 20. For example:

-   -   Bluetooth is a simple wireless interfacing medium which operates        over a relatively short range using radio frequency        communications;    -   IrDA is an infrared, line of sight, wireless interfacing medium        which is useful when the devices can be kept in close proximity        to one another;    -   Devices that accept data cables typically employ a cable which        has one end that conforms to the a device specific port or        connection point and the other end conforms to a USB interface,        accordingly, two devices can be interconnected via their        respective data cables and a USB gender converter to connect the        two USB ends of those cables;    -   Each device can be hooked up via two available USB ports on a        computer, with a “bridging software” operative thereon to        facilitate data transfer/information exchange between the        devices; or,    -   Each device can be connected one at a time to a computer and via        use of an appropriate agent on the computer; buffered data        transfer can take place.    -   Use of Short Message Service (SMS) can also be employed as a        means of communication between the devices. Typical SMS messages        are restricted in size, so the data transmission may optionally        progress in several messages rather than one long message.

It is to be appreciated that in connection with the particular exemplaryembodiments presented herein certain structural and/or function featuresare described as being incorporated in defined elements and/orcomponents. However, it is contemplated that these features may, to thesame or similar benefit, also likewise be incorporated in other elementsand/or components where appropriate. It is also to be appreciated thatdifferent aspects of the exemplary embodiments may be selectivelyemployed as appropriate to achieve other alternate embodiments suitedfor desired applications, the other alternate embodiments therebyrealizing the respective advantages of the aspects incorporated therein.

It is also to be appreciated that particular elements or componentsdescribed herein may have their functionality suitably implemented viahardware, software, firmware or a combination thereof. Additionally, itis to be appreciated that certain elements described herein asincorporated together may under suitable circumstances be stand-aloneelements or otherwise divided. Similarly, a plurality of particularfunctions described as being carried out by one particular element maybe carried out by a plurality of distinct elements acting independentlyto carry out individual functions, or certain individual functions maybe split-up and carried out by a plurality of distinct elements actingin concert. Alternately, some elements or components otherwise describedand/or shown herein as distinct from one another may be physically orfunctionally combined where appropriate.

In short, the present specification has been set forth with reference topreferred embodiments. Obviously, modifications and alterations willoccur to others upon reading and understanding the presentspecification. It is intended that the invention be construed asincluding all such modifications and alterations insofar as they comewithin the scope of the appended claims or the equivalents thereof.

1. A method for transferring content between a first mobile device and asecond mobile device, said method comprising: (a) internally storing thecontent on the first mobile device using a first data representation forthe internally stored content on the first mobile device; (b)establishing a common syntax and associated semantics for describing thecontent; (c) creating a first external manifest on the first mobiledevice from the internally stored content on the first mobile, saidexternal manifest employing the common syntax and associated semanticsto describe the content; (d) transferring the content from the firstexternal manifest to a second external manifest created on the secondmobile device, said second external manifest also using the commonsyntax and associated semantic to describe the content; and, (e)internally storing the content on the second mobile device using asecond data representation for the internally stored content on thesecond mobile device.
 2. The method of claim 1, wherein the second datarepresentation is different from the first data representation.
 3. Themethod of claim 1, wherein the first mobile device is one of a mobiletelephone, a smart phone and a personal digital assistant, and thesecond mobile device is one of a mobile telephone, a smart phone and apersonal digital assistant.
 4. The method of claim 3, wherein thecontent is a contact list.
 5. A method for transferring content from afirst mobile device to a second mobile device, said content including aplurality of different types of data elements, each particular dataelement having a particular value, wherein the content is storedinternally on the first mobile device using a first device-specificinternal data representation and the content is stored internally on thesecond mobile device using a second device-specific internal datarepresentation, said method comprising: (a) establishing a plurality ofcommonly recognized labels for identifying the different types of dataelements; (b) communicating from the first mobile device to the secondmobile device a first list containing one or more of the commonlyrecognized labels, wherein the labels contained in the first listindicate which types of data elements are available for transfer fromthe first mobile device to the second mobile device; (c) communicatingfrom the second mobile device to the first mobile device a second listcontaining one or more labels selected from the first list, saidselected labels contained in the second list indicating which types ofdata elements are to be transferred from the first mobile device to thesecond mobile device; and, (d) transferring from the first mobile deviceto the second mobile device the values of those data elements identifiedby the selected labels contained in the second list.
 6. The method ofclaim 5, wherein the second data representation is different from thefirst data representation.
 7. The method of claim 5, wherein the firstmobile device is one of a mobile telephone, a smart phone and a personaldigital assistant, and the second mobile device is one of a mobiletelephone, a smart phone and a personal digital assistant.
 8. The methodof claim 7, wherein the content is a contact list.
 9. The method ofclaim 5, wherein the selected labels contained in the second list arelisted in an order indicative of an order in which the second mobiledevice expects to receive the values of the data elements.
 10. Themethod of claim 9, wherein the values of the data elements transferredfrom the first mobile device to the second mobile device are transferredin the order expected by the second mobile device.
 11. The method ofclaim 10, wherein prior to the transfer of the values of the dataelements, the second mobile device communicates to the first mobiledevice a number indicating its capacity to accept the same.
 12. Themethod of claim 10, wherein subsequent to the transfer of the values ofthe data elements, the second mobile device communicates to the firstmobile device a number which indicates a count of the data elementsactually received.